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grcnTTON I ABSTRACT 


The purpose of this paper is to discuss some organizational aspects of programs using the actor 
mod el ^of Computation. In S.E paper we present an approach to modelling intelligencentermsofa 
society of communicating knowledge-based problem-solving experts. In turn *'** **££ 
viewed as a society that can be further decomposed in the same way until the primitive actors of the 
system are reached. We are investigating the nature of the communication £ 
effective problem-solving by a society of experts and the conventions of discourse that make this 
possible. In this way we hope eventually to develop a framework adequate f °r discussion of th 
central issues of problem-solving involving parallel versus serial processing and centralization versus 

decentralization of control and information storage. 

This paper demonstrates how actor message passing can be used to understand controlI structur« 

as pa,terns of passing message, In serial processing This paper ,s a n' e The abimy to 

treat issues of parallelism and communication within the framework established here The abiluyt 
analyze or synthesize an, kind of control structure a, a pattern of passing me,age, among the member, 
o? a s«°«y pmv'des an important tool for understanding control strut,ores. Ultimate,,, we hope to be 

able to characterize yariou, control slructures In common use b, societiesIn. , '™ ! «££& 
messages. This paper makes a small step in this direction by showing how to characterize familiar 

control structures such as Iteration and recursion in these terms. 
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SECTION II — METHODOLOGY 


Ill — Modeling an Intelligent Person 

Newell [1962] characterized what has become the conventional metaphor for computer problem 
solving as follows: The problem solver should be a tingle personality, wandering over a goal net much as 
an explorer wanders over the countryside, having a single context and taking it with him wherever he 
goes." Working within this paradigm, authors of problem solving programs have often relied on 
introspection as to methods that they would personally use to accomplish the task. Excellent scientific 
work has been done working within this metaphor. Some of the work has taken the form of writing a 
program to perform a task which requires a high degree of problem-solving ability in a human. Other 
work has attempted to model how an individual human actually performs a simple task at art 
information processing level. 

Research in any scientific field is carried out within the framework of underlying theories. A 
large portion of the research that has been done in the field of Artificial Intelligence has taken the 
modeling of an artificial human as its implicit goal. An early form of this modelling paradigm was the 
goal of constructing devices which would pass the "Turing Test" By this test a device is intelligent if It 
cannot be distinguished from a human by interaction through a teletype. However, the "Turing Test" 
view of the goal of artificial intelligence has been abused in recent years. Transcripts that appear to be 
interactions with programs have been published that give a very misleading impression of the real 
capabilities of the process that produced the transcripts. 

II.2 — Modeling a Society of Experts 

Reciprocal communication of a cooperative nature is the essential 
intuitive criterion of a society. 

Edward 0. Wilson in SOCIOBIOLOGY 

We are investigating the problem solving model of a society of experts to supplement the model 
of a single very intelligent human. We submit that this change in focus has several beneficial results. 
It provides a better basis for naturally introducing parallelism into problem-solving since protocols of 
individual people do not seem to exhibit much parallelism. The change in focus helps to make 
mechanisms for the communication of knowledge more explicit. Psychologists have found it extremely 
difficult to discover the communications that occur in the mind of an individual expert during problem 
solving. Also the justifications for statements becomes more explicit since one expert will often demand 
explicit justifications for the statements of another expert. It helps make the goal structures of 
programs more explicit since experts can demand to know why they are being asked to work on a 
particular task and how this task fits in with other tasks that are being pursued. Furthermore the 
change should foster better specifications for tasks to be achieved so that appropriate experts cart be 
selected or synthesized. 
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In these ways we hope to develop the communication mechanisms that are necessary to achieve 
cooperation between expert modules for various micro-worlds in order to perform larger ^swhc 
call for the expertise of more than one micro-world. Our work is attempting to build on the analysis 
that has been done by philosophers of science in recent years on the structure of the processes used y 
scientific societies. In particular the work of Kuhn and Popper and their followers provides « with a 
large stock of problem-solving ideas. The long term goal is to construct systems whose behavio 
approximates the behavior of scientific societies. ThaHv 
model the way scientists construct, communicate , test, and modify theories 


II3 — The Actor Programming Methodology. 

We are developing methods to specify the behavior of actors (objects) in terms that are natural to 

the semantics of the causal and incidental relationships* among the objects. That »s we t ar re 
to develop a transparent medium for constructing models in which the control structure emerges a»JL 
pattern of passing messages among the obj e cts being modeled 

Towards that end, we are developing a programming methodology consisting of the following 
activities: 


Deciding on the natural kinds of actors (ob jects) to have in the system to be constructed. 
Deciding for each kind of actor what kind of messages i t sh ould receiv e. 

Deciding for each kind of artnr what it should do when it re ceives each kind of message . 


Making the above decisions should constitute the design of an implementation^ Thus the data 
structures an3 control structures of the implementation shouldb^^^ 

of being determined by the limitations of the programming language being used. Th s is not to say 
that the resulting Implementation should be unstructured. Rather the structure of fbe imp'ementation 
should develop naturally from the structure of the system being modeled working within the 

conventions of discourse among actors. 

Actors are a local model of computation. There is no such thing as "action at a distance" nor U 
there any "global state* of all actors in the universe. Actors Interact on a purely local way by sending 

messages to one another. 


1: Causal relationships are 
incidental relationships are 


determined by physical causation in activating computational events whereas 
determined by the local order of arrival of messages at their destinations. 
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SECTION III — THE ACTOR MODEL 


HIl — Actors 

The basic construct of our computation mode! is the ACTOR. The BEHAVIOR of each actor is 
DEFINED by the relationships among the events which are caused by the actor. 

At a more superficial and imprecise level, each actor may be thought of as having two aspects 
which together realize the behavior which it manifests: 

the ACTION it should take when it is sent a message 

its ACQUAINTANCES which is the finite collection of actors that it directly KNOWS 

ABOUT. 

We first discuss actors in terms of their physical arrangement because it makes the discussion 
more concrete and familiar to most readers. Gradually the emphasis will change to a discussion of the 
behaviors realized by actors. 

Diagramatically we will represent a situation in which an actor A knows about an actor B by 
drawing a directed arc (which may be labeled for the convenience of the reader) from A to B. 



A directly knows about B as "friend" 
B directly knows about A as "support" 
A directly knows about C as "n" 

B directly knows about C as "father" 

C directly knows about D as "door" 


Diagram of the acquaintances of actors A, B, C, and D 
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" Th , - - - - — - —' “ q " ' 

For example 


(acquaintances A) 
(acquaintances B) 
(acquaintances C) 
(acquaintances D) 


[CB1 
{A C} 
{ 0 } 
n 


Note that the KNOWS ABOUT 

The acquaintances or on actor are —— - - 
example a list l with first element X and rest Y 



Diagram showing L dlrectljr mows about * as "first' and V as rest 

Of L could be in terms of a Imbed list, a vector ot storage, or even a 


The actual physical representation 
hash table: 
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LIWK.E5 list VECTOR H^SH TABLE 


Diagram showing alternative physical realizations of L 

Actors are straightforward to implement on conventional machines. We will mention a couple of 
ways to do this in order to add concreteness to our discussion. Practical implementations are particularly 
easy to construct using list-processing languages and micro-processors. Our implementation of actors in 
LISP uses one cons pair for every actor. One component of the pair is a LISP procedure which 
provides an entry point into the machine code necessary to implement the behavior of the actor when it 
is sent a message. The other component of the pair is an ordered list of the acquaintances of the actor. 
A similar representation could be used on a micro-processor (such as the CONS micro-processor of 
Knight et. al.). A reference to an actor on a micro-processor would in general require one word of 
memory which consisted of two sub-fields. One field woutd be used as an index into the micro-code 
and the other field would be used to point to a vector of the acquaintances of the actor. 

The reader should keep in mind that within the actor model of computation there is w o way to 
decompose an actor into its parts. An actor is defined by its behavior; not b y its physical 
representation! 
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III.2 


Components of the Actor Model 


The actor message-passing model is being developed as four tightly related and mutually 
supportive components: 

I A method for the rigorous specification of behaviors from various perspectives. 

An important degree of flexibility available in actor semantics Involves the ability to 
carefully control the articulation of detail to be included in specifications. That is. 
the constraints on the behavior of a system of actors can be specified in as much or 
as little detail as is germane. Too much detail is distracting and impractical. Too 
little detail fails to specify important aspects of the desired behavior. The wrong 
kind of detail deflects attention down fruitless paths. Often the specifications need 
to be very highly articulated for some crucial aspects of the desired behavior and 
less so for other aspects. We are developing a methodology through which the 
desired behavior of a system can be specified by axioms which characterize the 
relationships among the events which must constitute the behavior of the system, 
the highest level these axioms are specifications of what is to be done rather tha n, 
how As more detailed constraints of the allowable events are gradually imposed, 
the possible behaviors which will realize these constraints become more restricted 
until one is uniquely determined. Conversely, in order to demonstrate that a set of 
specifications is satisfied by a particular actor, one examines the behaviors of the 
component actors and demonstrates that the connection of these behaviors realizes 
the behavior that is required. 

2: A system (called PLASMA for PLANNER-like System Modeled on 
Actors) implemented in terms of actor message passing that is conv ^ nt J° r thC 
interactive construction of scenarios, scripts, and justifications. A SCRIF1. ,s a 
PLASMA program which can be used to specify the action that an actor will take 
when it receives a message. In our research we have attempted to investigate 
semantic instead of syntactic issues. We have designed PLASMA to be a 
transparent medium for expressing the underlying semantics of actor 
message-passing. For example the semantics of the "knows-about relationship for 
actors dictates that PLASMA must use a particular syntactic rule (lexical binding) 
for the referents of identifiers. The semantic model specifies that acquaintances of 
an actor must be specified when the actor is created. PLASMA satisfies this 
semantic constraint by using the values of the identifers at at the time of creation 
for the free identifiers in the script of a newly created actor since these are the on y 
actors available to be used as acquaintances. 

3- A m athematical theory of computation which can represent any kind of 
discrete behavior that can be physically realized. Our goal is to have a robu£ 
theory whose theorems are not sensitive to arbitrary conventions and definitions. A 
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theory which will be widely applicable as a mathematical tool is needed for 
formalizing and investigating properties of procedures. Currently our theory takes 
the form of a set of laws that any physically realizable actor system must satisfy 
together with a set of axioms that characterize the behavior of a powerful modular 
set of physically realizable actors (the primitives of PLASMA) which embody 
conventions for discourse among actors. 

4: The Event Diaerams presented in this paper are a further development of a 
graphical notation used by Richard Steiger in his masters thesis for displaying 
relationships among the events of an actor computation. In this paper we use them 
to show the causal and knowledge relationships that characterize simple control 
structures such as iteration and recursion as patterns of passing messages. Given an 
outline of important hypothesized events and causal relations among the events of a 
particular computation (i.e. a SCENARIO of the intended behavior of the system), 
event diagrams aid in abstracting scripts of modules that are capable of realizing 
this behavior. For example we plan to explore the abstraction of the scripts of 
actors for simple procedures for data structures from scenarios of their intended use. 
Conversely, they aid in the analysis of an existing system by graphically displaying 
the relationships among the events occuring in the system for particular cases of 
behavior. Using the displays available on our time-sharing system, we would like to 
automate the construction and analysis of event diagrams that have been done by 
hand in this paper. We would like to investigate the construction of an " eclectic 
magnifying glass " which provides flexible ways to specify which events and 
relationships in the history of a computation are to be be displayed. 


This paper introduces and describes the relationship between Event Diagrams and PLASMA for simple 
computations that do not involve side-effects. Issues of parallelism, inter-process communication, and 
synchronization will be treated in subsequent papers building on the foundation provided by this paper. 
For a mathematical treatment of the actor model of computation see (Greif and Hewitt: 
SIGACT-SIGPLAN 1975) and (Greif: dissertation 1975). Issues of behavioral specifications are treated 
in (Greif: dissertation 1975), (Hewitt and Smith: Towards a Programming Apprentice 1975), (Yonezawa: 
Symbolic Evaluation as an Aid to Program Construction). 
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SECTION IV ACTOR CONTROL STRUCTURE 


IV.t — Introduction to Event Diagrams 

From a strictly input-output point of view there is no difference between iterative and 
non-iterative implementations of a module. In order to rigorously analyze control structures it is 
necessary to have a model of computation that is capable of displaying the internal structure of 
computations . 

We shall use event diagrams to display the internal structure of computations. Such diagrams 
can be used to display many of the significant internal structural relations in a computation. A legend 
for the notation used in these diagrams is given on the next page. 
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Legend for Event Diagrams 



the box represents the actor A 







the "railroad tracks" are used to indicate that the 
occurrence of event Ej results in the occurrence of the 
event E 2 and thus Ej must precede E 2 in time. The 
event Ej has messenger Mj and target Tj whereas the 
event E 2 has messenger M 2 and target T 2 
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IV.2 — Actor Transmission 


Actors make use of one universal communication mechanism called A CTOR TRANSMISSION 
which consists of sending one actor (called the MESSENGER of the transnlssto) to another aoo, 
(called the TARGET of the transmission). Each actor transmission defines an EVENT ^ ^ 

MESSENGER arrives at the TARGET. The target and messenger are the immediate 
PARTICIPANTS in the event. I.E. if E is an event with messenger actor M and target actor T then 

(participants E) = {M T} 

Actor transmission enables the knowledge in the local context of the target actor T to be integrated 
with the information of the messenger actor M since the acquaintances of both 1 

are available for use when the messenger arrives at the target. Furthermore this constitutes the onl* 
information available at the Instant of computation defined by the event!!! 



Event recording the transmission of Messenger M to T 
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Actor transmission is used to provide the necessary communication between actors to accomplish 
the following kinds of actions: 

calling a procedure 

obtaining an element from a data structure 
invoking a co-routine 
modifying a data-structure 
returning a value 

synchronization of communicating parallel processes 

The actor transmission communication mechanism enforces the modularity and protection of actor 
systems. It provides the basis for constructing actor systems with explicit modular interfaces such that 
user of a module (actor) can only depend of the behavior of the actor. The hardware enforces the 
c&nstraint that the user of a module cannot depend on its current physical representation. 

IV.2.a — Messeneers 

In order to have a useful model of a message-passing system, the problem of infinite regress must 
be explicitly addressed. The actor message passing model provides for primitive actors to deal with 
this problem. When a primitive actor receives a request, it is unnecessary for the primitive to send any 
further messages in order to properly respond to the request. In particular this means that a primitive 
actor must be able to obtain some of the acquaintances of a messenger which it receives without having 
to send any messages. Packagers (see appendix) provide the primitive mechanism needed in PLASMA 
for transmitting messengers between actors. 

Once an actor, m, (serving as messenger) is transmitted to another actor (serving as the target), i 
the computation proceeds by following the script of t using information from m. For this to be of any 
use as a model of communication, it must be that m obeys some fairly standard conventions. These 
provide the basis for meaningful discourse between actors. We will adopt the convention that all of the 
messengers constructed by the PLASMA system are packagers^ of the following form. 

(messenger: (agent: a) (envelope: e) {banker : b)) 

where a is an actor representing the agent responsible for the computation, • is the envelope of the 
transmission, and b is the banker funding the computation. The explanation of bankers and agents is 
outside the scope of this paper so we shall say no more about them. 


2: Readers who are unfamiliar with the packagers of PLASMA may wish to consult the appendix. 
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IV.2.b — Envelopes 

In many cases the envelope of a messenger will simply contain a message. A response to a request 
is either a REPLY envelope with a reply message to the request packaged as 

( reply, the-massaga ) 

or a COMPLAIN envelope with a complaint message packaged as 

{complain: tha-massage ) 

which explains why the request could not be honored. 

Often the envelope of a messenger is a REQUEST which in addition to a request message 
contains an actor c to which a reply to the request should be sent. Such an envelope is packaged as 
f ollows: 

Irequett: lha-messaga ( reply-to: c)) 

The ACTOR c is closely related to the continuation FUNCTIONS used by Morris, Wadsworth, 
Reynolds, and Strachey. 

An ordinary functional call to a function f with arguments argj.through arg k is implemented 

in PLASMA by passing to f a request envelope with a message consisting of the tuple [argj,..., arg K ]of 
arguments and a continuation actor to which the value of I should be sent. 

IV,3 — Request and Reply 

Perhaps the simplest control structure is the ordinary request and reply pattern of activity that is 
implemented in most programming languages as a procedure call and return. None of the internal 
structure of the actor being invoked is shown. Instead the description articulates only the input-output 
behavior of the actor. 
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Consider the example of a request being sent to an actor factorial to compute its value for the 
argument tuple [3] and send the answer to the actor C. The diagram shows the two events consisting of 
the above REQUEST (i.e. factorial is sent a messenger with message [3] and continuation C) and the 
REPLY in which C is sent a newly created messenger Mjj with message 6: 



An Event Diagram for the Computation of (factorial 3) 

The above event diagram treats factorial as a "black box" with none of the internal events shown. 
Notice that the computational process follows the "railroad" tracks from the first event to the second 
event. We will now proceed to examine the computation more closely. This is an application of the 
idea of using an eclectic magnifying glass to articulate the description of a behavior in greater detail 
What is seen depends on how factorial is implemented as well as the focus of the magnifying glass 
When we look into the implementation of factorial, we will see a number of events that occur between 
the two which are diagrammed above. 

Note that the value 6 which is constructed by the actor factorial is not an acquaintance of factorial. 
Instead it is the "reply" acquaintance of the messenger M2 which is sent to the continuation C. 
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IV.4 — Recursion 


IV.4.a — Scripts for a Non-Iterative Factorial 

Suppose we have a non-iterative implementation of factorial. A script written in PLASMA for 
such an implementation is given below. Readers who are unfamiliar with the notation can consult the 
appendix which provides an informal introduction to PLASMA. 


(factorial s 
(£> [=n] 

(rules n 
(s> 1 
1 ) 

(s> 0 1) 

(n * (factorial (n - l))))))) 


factorial it defined to be 
;receive a menage with one element which will be called n 

;the rulet for n are 
;if it it 1 
;t hen return 1 
;elte if it it greater than 1 then 
;return n timet factorial of n minut 1 
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IV.Tb — An Event Diagram for factorial Calling Itself Recursively 

We are interested in looking more deeply into the control structure of recursive procedures. To 
this end we take the above non-iterative implementation of factorial as a concrete example to be studied. 
When factorial receives the message [3] it is not able to reply immediately since it does not directly know 
what (factorial 3)is. Below is an event diagram of the computation that results from sending factorial a 
messenger Mj with message [3] and continuation C up to the point of the first recursive call in which 
factorial is sent a newly created messenger M 2 with message [2] and continuation C’ where C’ is a newly 
created actor that knows about n and C. The script of C’ is such that whenever it is sent a message y, it 
sends C the message (3 * y). 
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IV 4 c — Snapshot of Storage at Instant when factorial receives [lj 

Below we present a snapshot of the storage at the instant factorial receives the message [1]. The 
rule for computing the amount of storage being used at the instant of any particular event is very 
Simple: Merely count all the actors that are in the transitive closure of the acquaintances of the 
participants involved in the event. Recall that the participants of an event are the actors immediately 

Involved (i.e. the target and messenger). 
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IV.4.d — Viewing Recursion as a Pattern of Passing Messages 

The above event diagram exhibits the characteristic structure of a recursive computation. This 
pattern is familiar to users of ALGOL, LISP 1.6, and PL-1 and other programming languages that 
make use of a pushdown stack to implement recursion. In such languages the amount of stack used by 
the implementation grows monotonically until factorial is called with the argument 1 and then 
monotonically decreases as the stack is popped. 

Below we give an event diagram that displays the pattern of passing messages characteristic of 
recursion in the computation of (factorial 3). Note that the computation proceeds from event to event 
along the "railroad tracks" in the diagram. 
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IV.4 s e — Characterization of Recursion as a Pattern of Passing Messages 

Thus we see how recursion can be characterized as a pattern of passing messages using event 
diagrams. The characteristic feature is the build up of a chain of continuation actors each o.ne of 
which knows only about the next and which eventually replies to the next with the answer. Notice that 
this characterization of recursion in terms of relations between events is independent of the syntax of 
the language for scripts which gives rise to the behavior. For example the same characterization would 
hold for a recursive implementation of factorial in ALGOL. The semantics of ALGOL can be defined 
using relations among events in a manner similar to the way in which the semantics of PLASMA is 
defined. 

a 

The existence of the actors labeled C' and C" in the above diagram and the events in which they 
are the target are difficult to explain in terms of the above PLASMA script for factorial. In order to 
explain the origin of these actors and events, we need to explain more of the underlying implementation 
of PLASMA. 


IV.5 — Envelope Level Scripts 

Thus far in our PLASMA scripts we have examined information communicated in the messages 
of envelopes. At this point we would like to introduce the envelope level which allows access to other 
information in the messengers of actor transmissions. Every messenger always contains (among other 
things) an actor which serves as the ENVELOPE. In turn every envelope always contains an actor 
which serves as the MESSAGE. Additionally REQUEST envelopes contain actors called 
CONTINUATIONS to which replies to the messages should be sent. 

The reason that it is useful to introduce the envelope level transmitters and receivers into scripts 
Is that otherwise much of the control structure (pattern of passing messages) has to remain implicit in 
something like an evaluator or a compiler. Envelope receivers and transmitters provide the mechanism 
for expressing more explicit scripts so that none of the processing or allocation of storage is going on 
behind the scenes. 

Envelope receivers and transmitters are analogous to ordinary receivers and transmitters in many 
respects. They are intended to be used as a notation for writing scripts in which all the computational 
events and actors are explicitly shown. In this way the structure of simple control structures such as 
iteration and recursion can be explicitly characterized as patterns of passing messages. 

PLASMA uses the syntactic convention of using the number of shafts on the transmitter and 
receive arrows to reflect the level at which the transmission is being referenced; one shaft meaning 
ordinary message level, and two shafts meaning envelope level. Thus: 

<= is an (ordinary) message-level-transmitter, and 

<rs is a envelope-level-transmitter. 
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Similarly, 

=> is an (ordinary) message-level-receiver, and 

==> is an envelope-level-receiver. 

Below we use this notation to make the message-passing underlying the implementation of PLASMA 
more explicit. 

For example an ordinary message receiver which receives one argument n and replies with the 
value (n + l)written as 


<*> [=nj 
(n + «) 


can be written at the envelope level as follows: 


(==> {request: [=n] (reply-to: =c)) 
(c <== {reply: (n + 1)))) 


iV.S.a — A More Explicit Script for the Non-Iterative Factorial 

The correspondence between the event diagram for the non-iterative implementation of fueteriei 
and its script can be made more apparent by using envelope transmitters and receivers to rtmake the 
underlying implementation explicit. The script presented below is intended to explicate how the 
implementation of PLASMA actually works. 


(factorial = 

(==> {request : [an] {reply-to: =c)) 


(rules n 
<=> 1 

(C <== {reply: 1))) 

< 3 > 0 1 ) 

(factorial <== 

(request : [(n - 1)] 
{reply-to: 

(==> {reply: =y) 


;factorial is defined to be 
;receive a request to compute the value of factorial /or 
;an argument tuple whose only element is n and 
trend the reply to the actor e 
;the rules for n are 
;if it is 1 then 
trend c a reply envelope with message 1 
telse if it is greater than 1 
;scnd factorial a request 
;u>ith message (rs - 1) and 
;continuation the following actor 
;if a reply envelope with message y h received 
(c <== ( reply, (y * n))))})))))) ;i hen send c a reply envelope with message (y $ rt| 


Notice that the above script specifies that before recursively calling factorial (in the case where m*l), a 
new actor is created as the reply-to: component of the envelope sent to factorial. This new actor is 
created with ACQUAINTANCES n and e and has the following SCRIPT: 
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(s=> ( reply. =y) 

(c <= [reply, [y * n)))) 

Operationally, the script says *for each reply y that It received, multiply it by n and tend the retailing 
product as a reply to c". 
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IV.6 - Iteration 

It is well known that another, more efficient implementation of factorial uses iterative control 
structure. Event diagrams will be used as a too! to illustrate the behavior of this more efficient 
implementation of factorial. One idea for an iterative implementation is to gradually build up the 
product while counting down the argument -doing one multiply for each iteration. So we define an 
actor called loop which should be sent both the current accumulation (which is initially 1) and the current 
count (which is initially the input n) on each iteration. The obvious way to do this is to repeatedly send 
loop a sequence of the form [accumulation count]. 


IV.S.a — A Script for an Iterative Implementation of Factorial 


(factorial a 
<—> [-nj 
([1 nj => 

(loop s 

(~> [^accumulation =countJ 
(rules count 
(=> l 

accumulation) 

<=> 0 1 ) 

(loop 


{factorial is defined to be 
{receive one argument and call it n 
;* end a 2-tuple with elements 1 and n to 
;a newly created actor named loop which behaves as follows 
;receive a 2-tuple as the current accumulated product and count 

;the rules for the count «r@ 
;if it Is 1 then 
{return the accumulation 
;else if it is greater than I 
{Mend loop 


(accumulation * count) 
(count - 1))))))))) 


{the accumulation times the comM 
{and the count minus on» 


Notice that the argument n is not an acquaintance of the actor loop in the iterative 
implementation of factorial. The rule for calculating the acquaintances from the script of an actor 
defined in PLASMA is very simple: the acquaintances of a newly created actor are the actors named by 
the free identifiers in the script at the time the actor is created. Instead of being an acquaintance, the 
actor n is sent to loop as the second element of the two tuple [1 nj. 
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IV.6,b — An Event Diagram for Iterative Factorial 

The script given above will exhibit the behavior diagramed below when factorial is sent the 
message [3], This is an illustration of iteration as a pattern of passing messages. Note the repeated use 
of the actor C as a continuation in the envelopes used in the iterative implementation of factorial. 
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IV.6.C — A More Explicit Script for Iterative Factorial 

Notice that the above implementation of factorial definitely uses iterative (finite-state) control 
structure in the sense that it does not need any more memory than that needed for the values of count 
and accumulation. We now incorporate envelope transmitters and receivers to make the script of the 
iterative implementation of factorial more explicit. In this way the correspondence between the event 
diagram for the iterative implementation and its script becomes more apparent. 


(factorial = ;factorial is defined to be 

(==> (request: [=n] ;receive a request with argument tuple [nj 

(reply-to: =c)) ;a nd continuation e 

((request: [1 n] (reply-to: c)) ==> ;send a request with argument tuple f J. n] and 

;continuation C to the. following newly created actor 
(loop 3 ;named loop 

(=£> (request: [=accumulation =COunt] (reply-to: =d)) ;such that if a request is received with 

;message containing the accumulation and count 

;and continuation d 

(rules count ;checks the comm 

(=> 1 ;l» see if il is I 

(d <== (reply: accumulation))) ;if so it sends the accumulation as a reply to d 

(=> (> 1) ;else if it is greater than i then 

(loop <== ;send loop a request with 

(request: [(accumulation * count) (count - 1)] ;the appropriate message 

(reply-to: d)))))))))) ; and the continuation d 


The reason that this is iterative is that loopalways passes along the same continuation actor that it 
receives with the message. The only continuation it needs, and therefore the only one that it holds onto, 
is the one contained in the original envelope that was sent to factorial. The loop sends its answer to that 
continuation directly when it is done Thus no extra storage is needed going around the loop. 
Furthermore, in this implementation of iteration there are no side effects which change the behavior of 
any actor. If the user wants, she can keep a complete history of all the events in her computation and 
be confident that no information has been lost. Actor semantics account for the iterative behavior of 
the above implementation of factorial without having to appeal to external implicit mechanism such as 
an interpreter or any kind of external storage mechanism such as activation records. AH the behavior 
of the system is accounted for by the behavior of actors when they are sent messages. Furthermore all 
of the storage is accounted for by the actors shown in the event diagrams. Event diagrams show how 
PLASMA 1? actually imple mented using actors. The actor model provides a complete self-contained 
rigorous theory of iteration as a pattern of passing messages. It provides an explanation for the 
semantics behind the optimization rule used by many compilers that all "tail recursive" self-referential 
definitions can be compiled using special iteration primitives such as "while” loops, ”do“ loops, etc. 
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The term RECURSIVE Has come to have at least three different meanings in computer science: 


1: Effectively computable as in "recursive function theory 

2: Self-referential as in "factorial can be defined recursively in terms of itself" 

3: Non-iterative as in "recursive functions use up more push-down stack when they 
call each other whereas iterative loops do not. 


word. 

Using factorial as a simple example, we have shown how the actor message passing model can be 
used to give additional precision to fundamental concepts in computer science. 
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IV.7 — Comparison of Recursion and Iteration 

Below we present abstracted versions of the event diagrams for the iterative and non-iterative 
implementations of factorial when called with 3 as an argument. In the diagrams below the message is 
shown inside the messenger in order to more strongly bring out the pattern of message passing. 


RECURSION 



ITERATION 
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SECTION V — EFFICIENCY and INTELLIGIBILITY^ 


V.l 


- Modular Distribution of Knowledge 


Since the defining characteristic of actors is that they send and receive messages, they are 
relatively unbiasrf with respect to assumptions about control structure and the distinction and 

and operators The neutrality on the issue of division of knowledge between data structure and 
operators can be seen in the various ways in which one can distribute information m ^ actor systern 

How, one might choose to distribute it depends on one’s purposes and the \Y ,OU ! h U rf? ffere nt use* of 
knowledge can be put. Often it is desirable to represent knowledge redundantly with different use 
the same S knowledge appearing in several guises in several different places. The point is that the actors 
allow distribution of knowledge in any way that is useful. 

Early Artificial Intelligence programs were mainly organized as multi-pass heuristic programs 
consisting of a pass of information gathering, a pass of constraint analysis and a pass of hypothesis 
formation. I. is now generally recognlred that multi-pars organization, of thuI kind are Inflexl .1. 
because It Is often necessary for information to flow across these boundaries In both direction. In a 
dialogue at all stages of the processing. 


V.2 


Non-hairy Control Structure 


One of the most important results that has emerged from the development of actor semantics has 
been the further development of techniques to semantically analyze or synthesize controlstructuresasa 
patterns of passing messages. As a result of t h is work, we have found that we can do 
p.a-cp^ rnX Of "hairy control structure" (such asj H?»MitrM^^ 

vl„ tn the internal variables of otheLp rocedures in CONNIVER), None of the accouterments ^, 

”hairy~control structure” seem to be necessary for communication among tbe P* 11 .*. * S v a !,d 
goal-oriented formalism. In particular "hairy control structure is not needed to deal effectively and 
efficiently with anomalies and complaints encountered in the course of attempting to mechanize 
problem solving in such a formalism. The conventions of ordinary message-passing seem to * 

better structured, more intuitive, foundation for constructing the communication systems needed Tor 
expert problem-solving modules to cooperate effectively. 

We have discovered a syntactic transformation by which it is possible to convert a program which 
uses hairy control structure into an equivalent program that uses ordinary message passing. The first 
step of the transformation is to convert each ordinary message receiver s> into the form ==> and each 
ordinary message transmitter => into the form ==> using the techniques used in the exam P’ es ab ^ 
The next step then simply to convert each envelope level receiver *> into and each each en p 

level transmitter ==> into =>. The result is a program which make no use of hairy control structure. 
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However, it is not recommended that the above method be used to convert programs that use 
hairy control structure. The best way to achieve an efficient modular implementation of a problem 
solver is to reason directly in terms of the behavior required to solve the problem. It is highly 
undesirable to take a program that is difficult to understand because of the use of hairy control 
structure and "improve" it by eliminating the hairy control structure by a local syntactic transformation 
such as the one discussed above. In general such local transformations make badly structured 
programs worse instead of better. 

We will present two examples of problems where hairy control structure was originally used to 
implement a difficult problem. As the problem to be solved has become better understood, more 
intelligible solutions which do not involve hairy control structure have been developed. 


V.3 — Gaining Efficiency thru Progressive Refinement 

Efficient implementations of systems are usually most easily arrived at by beginning with a 
high-level goal-oriented plan and then progressively refining using specific domain-dependent 
knowledge. For example a simple recursive implementation for computing basa* x P° n * n * is given below: 

(integar-axponentialion s 
(=> [=basa -exponent] 

(rules exponent 
(=> 0 
1 ) 

(else 

(base * (integer-exponentiation base (exponent - 1))))))) 

In the above example we have made use of an expression of the form 

(e/*e body ) 

as a convenient mnemonic abbreviation for 

(=> ? body ) 

making use of the fact that the pattern T will match anything. 

The above plan is too inefficient to use to calculate large exponents. However, we do not intend 
to use it for this purpose! Instead of executing the plan, we propose to refine it to make it more 
efficient. These refinements have been accomplished by using a great deal of mathematical and 
problem solving knowledge. 

The efficiency of the exponentiation routine can be improved by transforming it into an iterative 
form using the fact that integer multiplication is associative: 
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(integer-exponentiation s 
(s> [abase =exponent] 

([exponent 1] => 

(till-exponent-zero s 
(=> [=e ^accumulation] 

(rules e 
(=> 0 

accumulation) 

[cite 

(till-exponent-zero 
(e- 1) 

(accumulation * base))))))))) 

However, the above procedure is still not very efficient. 

Notice that if exponent is an even integer then 

ba sa «xp°"ent - (base * b«e)<• ,< * >one " , 1 2) 

The above arithmetical fact can be used as the basis for making a faster exponentiation routine: 

(last-exponentiation s 
(=> [sfease =exponent] 

([base exponent 1] => 

(till-exponent-zero 3 
(=> [=b ae =accumulation] 

(rules e 
(=>0 

accumulation) 

(s> ( even) 

(till-exponent-zero 
(b * b) 

(e/2) 

accumulation)) 

(else 

(till-exponent-zero 

b 

(e - 1) 

(b * accumulation)))))}))) 

This last refinement is probably fast enough for most practical purposes. However, John Reynolds has 
pointed out that the above program is still inefficient in two ways: 
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After it is determined that the exponent is odd, when the loop is continued it i* 
unnecessary to test that (exponent - l)is even. 


After it is determined that the exponent is non-zero but even, when the loop is continued 
it is unnecessary to test that (exponent / 2)i$ non-zero. 

Reynolds showed how these inefficiencies could be removed by the use of assignment statements and 
gotos. 

The double testing is easily eliminated in PLASMA by simply defining two auxiliary actors 
which handle positive and even exponents as special cases. This example demonstrates how the 
underlying strategies of optimizations can be captured by reasoning in terms of message-passing. 

(faster-exponentiation & 

(h> f>base -exponent] 
del 

(positive-exponent s 
(=> [;4i =# ^accumulation] 

(rules s 
(e> (even) 

(positive-exponent 
(b * b) 

(e / 2) 

accumulation)) 

(else 

(even-exponent 

b 

(e- 1) 

(b * accumulation)))))) 

(even-exponent = 

(=> [=b =e saccumulation] 

(rules e 
(s>0 

accumulation) 

(else 

(positive-exponent 
(b * b) 

(e / 2) 

accumulation))))) 

then 

(rules exponent 
(=> 0 
1 ) 

(else 

(positive-exponent base exponent 1)))))) 
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The ooint of this example is that viewing control structure as a pattern of passing messages can 

be usJ t motivate optimizations that inefficiency. A go* ^J 

writing high-level goal-oriented plans to specify a task followed by progressively reflnhig; theseans to 

ZZ efficient implementations. To support a programming methodology based 
refinement it is necessary to have a unified coherent formalism which can encompass * 

range of pians. The formalism need, lo be sufficiently powerful to represent an, potential optimliaiion 
so that the complexity and efficiency of the optimization can be calculated. 


V,4 — Generators 

In knowledge based systems, it Is unreasonable to store all the implication, of the knowledge 
available a° a given time Explicitly storing the answers to all possible questions Insteadof 

incrementally generate implications as needed in order to answer questions. 

In order to deal with this problem Newell, Shaw, Simon introduced a form of generates into 
their Information Processing Language. Since that time, the con cept has ^gone^consh em ^ 

further development. In terms of actors the idealsThat”. does not physically conialn all the 

~*"k “ «—* T ” mak ' —f d, T°" Jm plasm a** 

present 5 a simple problem .hat illustrates how generators can be conveniently implemented In PLASMA. 

We will assume lha, we have some actors tailed bees such that each tree ’ * 

(terminal: Tlwhere I i, the terminal symbol, or of the form (n„n-..™.n«l: L Rlwhere L and R 
right sub-trees. 

For example the tree 


( non-terminal: 

(non-terminal: (terminal: A) ( terminal: B)) 
(terminal : C)) 



has the following fringe (sequence of terminals In left to right order) (A B C] 
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as does the following tree: 


(non-terminal: 

(terminal: A) 

(non-terminal; (terminal: B) (terminal: C))) 


whereas the following tree 


(non-terminal: 

(terminal: C) 

(non-terminal: (terminal: A) ( terminal: B))) 


has [C A BJas its fringe. 



The problem is to define the actor fringe so that for any tree T, (fringe T) behaves like a sequence 
of the terminal elements of T. There are two important properties that characterize the behavior of 
fringe. First, fringe of a terminal node must behave like a sequence with one element 


(fringe (terminal; T)) " [TJ 


The symbol ~ is used to denote behavioral equivalence of actors. Second, fringe of a non-terminal node 
must behave like the sequence produced by concatenating the fringe of the left sub-node and the fringe 
of the right subnode: 

(fringe ( non-terminal : L R)) ~ [{(fringe L) {(fringe R)] 

The above specification makes use of the unpack operator { of PLASMA which is explained in the 
appendix. 
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V.4.a — A High-Level Implementation 

From the above behavioral specifications we can immediately derive the following 
implementation of fringe: 


(fring* = 

(=> [=the-tree] 

(rules the-tree 

(=> ( terminal : =T) 

IT]) 

(=> ( non-terminal: =L =R) 
[!(fringe L) *(fring* R)])))) 


;the behavior of fring# it defined to be 
;twhenever it receives a tree 
;the rules for the tree are 
;if it a terminal T 
;then the fringe it a sequence whose only element it T 
;else the tree must he a non-terminal 
;and the fringe of the tree it 
;the fringe of ilt left sub-tree concatenated with 
;the fringe of ilt right sub-tree 


Unfortunately, the above implementation is not incremental because it immediately looks at all the 
nodes of the tree and thus is exponentially inefficient. The above definition of fringe is still very much 
a specification of what fring# is supposed to do as opposed to a detailed specification of hos^ to 
efficiently accomplish the task. This lack of concern with the details of implementation is the chief 
advantage (and at the same time the chief disadvantage) of high-level implementations. 


f^\ 




V.4.b — An Incremental Implementation 

Incremental generation amounts to adopting a "wait and see" approach as to whether the rest of 
the elements will be needed. The above implementation of fringe can be refined to be incremental by 
use of the delay operator. Readers who are not familiar with the delay operator of PLASMA should 

consult the appendix. 


(fring* 2 ;the behavior of fring* it defined to be 

, r *h« traal ;whcnever it receive* a tree 

*£T rule* for th» tree ore 

. • | T \ ;»/ tt a terminal T 

(=> (terminal: =T) 

j-j-jj ;then the fringe it a sequence whose only element it I 

(=> (non-terminal: =1 =R) lhe tree mutt be a ^ n ^ rminal 

[|(delay (fringe LJ) lldelay (fringe R)}])») <“"<* »*• f*"g* the ,reeU 

ft he fringe of it* left sub-tree concatenated with 
.<1.0 nf its rieht tub-tree 


The "wait and see" approach is not always the most efficient implementation for every problem. 
In particular often there is a space-time trade-off in the use of the delay operator. In many cases it is 
more efficient to simply compute an expression E immediately than to wait by the use of (delay psince 
the latter can cause the retention of extra unnecessary storage. For example consider the following 
definition: 



i 
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(f 3 

<=> [=X =h] 

(rules x 
<=> « 3) 

0 ) 

(else 

h)))) 

Notice that the expression (f 2 HUGE immediately evaluates to 0 whereas the expression 
(delay (f 2 HUGE))is an arbitrarily large amount of storage which will eventually evaluate to 0. The 
reader might consider how the efficiency of the implementation of the delay operator can be improved 
using partial evaluation. 

An additional complexity is that PLASMA uses incremental sequences to implement pattern 
directed retrieval from a data base. This data base must have side-effects because it is used to 
implement communicating parallel processes [Greif and Hewitt 1975], In this application the "do it now" 
and "wait and see" implementations can result in different sequences of values! In or der to rnaSy; 
interprocess communication work properly, careful control must be maintained over when del a ys are 
introduced in to PLASMA scripts. This issue arises in the implementation of shared resources whos 
integrity must be protected as they are used by communicating parallel processes. For this reason 
PLASMA has been not been designed to use the delay rule for evaluation as the default evaluation 
mechanism as has been proposed for lambda calculus languages by Church, Cadiou, Vuiilemln, 
Wadswbrth, Henderson and Morris, and Friedman and Wise. Carried to its logical extreme the 
ultimate form of the uniform delay rule is to never compute the value of any expression unless the 
value is needed for output to the external environment! 
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SECTION VI — The LAMBDA CALCULUS of CHURCH 


As we have explicitly acknowledged in our previous papers, the development of PLASMA and 
the actor model of computation has been strongly influenced by the lambda calculus and by the work of 
numerous researchers who have studied it. The lambda calculus of Church is a suitable formalism for 
studying the behavior of effectively computable functions. 

In our research we have attempted to constructively build on this previous work by develop ingjt 
problem solving formalism and semantic model for actors such as cells, serializers, and funnels which.do 
not behave like mathematical functions In the sections below we investigate the different ways that 
previous researchers have used the lambda calculus as a formalism for studying the semantics of 
procedures. 

The actor model of computation is based on incidental and causal relations among events where 
each event is defined by the act of sending one actor to another. Thus it is incorrect to speak of an 
"actors interpreter" because a semantic model does not specify a language wh i c h can be executed ^ The 
relationship between actors and PLASMA is analogous to the relationship between mathematical 
functions and the lambda calculus. Although there is a well developed mathematical theory of 
functions as sets of ordered pairs, there is no such thing as a "functions interpreter". The lambda 
calculus is just one of many possible languages which can be used to define the behavior of 
mathematical functions. Similarly, PLASMA is just one of many possible languages that can be used to 
define the behavior of actors. 

In some useless sense all programming languages are equivalent. It is possible to simulate the 
behavior of any programming language using any other programming language in common use. 
Naively it might be thought that ALGOL is "more powerful" than FORTRAN because ALGOL has 
recursion and FORTRAN doesn’t. However, there is a programming style in FORTRAN which 
enables recursive programs to be written in FORTRAN corresponding very closely to the way in which 
the programs would be written in ALGOL. The simulation involves allocating a large array to hold 
the temporary values needed in recursion. Similarly it is possible to simulate the behavior of PLASMA 
using a lambda calculus interpreter. The table below gives a simulation method for important 
behaviors of actors: 


BEHAVIOR PLASMA 

PRIMITIVE 


mutual-reference labels 

side-effects cell 

synchronization serializer 

parallelism funnel 


LAMBDA CALCULUS 
SIMULATION TECHNIQUE 

Y operator 

"global state” of memory 
"global oracle" 

"global state" of program counters 


All of the above simulation techniques work by systematically adding extra arguments to lambda 
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expressions. To simulate cells [Scott-Strachey] an extra argument is added to every lambda expression 
which is to be bound to a lambda expression which contains the "current contents" of all the cells on all 
the machines of the system. An assignment of new contents to a cell is simulated by constructing a new 
lambda expression which simulates the "next global state" of all the cells on the machines. Similarly to 
simulate synchronization an extra argument is added to every lambda expression which is to be bound 
to a lambda expression which simulates the "next" instruction to be executed on one of the machines 
executing in parallel. Thus the lambda calculus can be used to simulate the behavior of an actor system 
running on a network of machines executing in parallel. The lambda calculus simulation approach 
attempts to model all behavior by reduction to lambda abstraction and application. This raises an 
important question: 

For what purposes is lambda calculus simulation a useful model of computation? 

The answer to this question is currently under investigation by many researchers. We suspect that it 
will be several more years before researchers have reached a consensus of opinion on the question. 
However, we can make a few preliminary remarks that bear on what the ultimate answer might be. 

Simulation using lambda expressions does not correspond very closely to the mechanisms that 

are a ctually used to implement communicating parallel processes on a network of machines 
executing in parallel. Networks of machines will soon become very common because of the rapidly 
decreasing cost of processors and rapid development of technologies to inexpensively provide 
high-bandwidth connections between machines. 

PLASMA attempts to provide modular primitives which are intended to be used to implement 
abstractions that manifest useful problem solving behaviors such as communicating parallel processes. 
Within the actor model of computation, the behaviors of primitives such as cells, serializers, and funnels 
are axiomatized using incidental and causal relations among events. The actor model is intended to 
serve as the semantic foundation for a Programming Apprentice that supports an evolutionary 
behavioral programming methodology. In order for a Programming Apprentice to communicate 
effectively with the programmers building a system, it needs a semantic model which closely corresponds 
to the way in which programmers think about their computations. The actor message-passing model 
corresponds closely to the mechanisms that are actually used to implement communicating_parafief 

processes on networks of machines. 
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SECTION VII — FUTURE WORK 


VIM ~ Applications 

The PLASMA system described in this paper is currently being implemented at the MIT 
Artificial Intelligence Laboratory. In the spring of 1975, PLASMA was defined meta-ctrcularly in terms 
of itself and then translated by hand into LISP using making use of LISP macros written by Russ 
Atkinson that make LISP resemble a subset of PLASMA. In the fall semester of 1975 the translation 
was completed and brought into an efficient running state by Howie Shrobe. However, more work is 
needed before it will be usable for writing large systems. This implementation [which has modularity 
and good human engineering as its chief design goals] is still under development. It is based on the 
actor transmission communication mechanism using primitive actors coded in LISP. The development 
of the actor metaphor will continue in the next year to gain some experience in using it for the 
following kinds of applications: 

to implement a distributed symbolic evaluator for a Programming Apprentice [Hewitt 
and Smith 1975, Rich and Shrobe 1975, Yonezawa 1975] 

(/ .. . ... 

to implement other procedural knowledge-based systems such as a stereotype-based visual 
perception system [McLennan 1975] 

as a formalism for defining message passing systems to try out ideas for the modular 
distribution of knowledge for a society of communicating experts 

to experiment with various scheduling and synchronization policies using serializers 
[Atkinson and Hewitt 1976] 


as a basis for a flexible actor-based animation language [Kahn 1976] 
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VH.I.a — Incremental Perpetual Development 

The development of any large system (viewed as a society) having a long useful life must be 
viewed as an incremental and evolutionary process. Development begins with specifications, plans, 
domain dependent knowledge, and scenarios for a large task. Attempts to use this information to create 
an implementation have the effect of causing revisions: additions, deletions, modifications, 
specializations, generalizations, etc. At all times in the perpetual development of the system the 
programmers are confronted with 

. .Is A progression of more refined plans [programs, implementations, etc.] 

which partially accomplish some of the tasks specified. 

2: Partial specifications [contracts, intentions, constraints, etc.] for some of 
the subtasks which are to be accomplished. 

3: Partial justifications [proofs, demonstrations, analysis of dependencies] 
regarding how some of the plans satisfy some of their specifications. 

4: Partial descriptions of some of the background knowledge 
[mathematical facts, physical laws, questions of interactive users, government 
regulations, etc.] of the environment in which the system will operate. 

5: A collection of scenarios [at various articulations of detail] 
demonstrating how the system is supposed to work in concrete instances. 

The success of an evolutionary behavioral modeling methodology is highly dependent on the 
development of competent Proeramming Apprentices [Hewitt and Smith 1975, R ich and Jshrofoe 
1 976, Vonezawa 1976] that help keep the above potentially disparate descriptions of a system 
c oherently organ ized. The primary benefit of maintaining this coherence is not to prove once and for 
all that the implementation is CORRECT in any absolute sense. Changes in the environment external 
to the system will require that the system must either adapt its behavior to the changed circumstances or 
be supplanted. Rather the chief benefit of demonstrating the coherence of multiple descriptions of 
a system is to make the dependencies arnone the parts explicit so that the system can be re adily 
adapte d to the perp etually changing external environment. Already for many systems considerably 
more money is spent on modification and enhancement than on initial design and implementation, 
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vt !9 - The Actor Problem-Solvin g Meta phor 

The actor metaphor tor problem solving is a large hu™n tb^clort. 

scientist. Each has her own duties, specialties, and con tacts ^ 

Communication is highly stylized and format using messages that 

Problem solving proceeds by the attempts of experts to> g>j ess > ° r t0 ’ “"^pjans for*:action are 
solution followed by attempts to criticize pr P ob , e m at hand. Tentative 

put forward for trial, to be eliminated or modi i g P demonstrated to be 

acceptance of a proposed plan must be combinedto live in a world 
infeasible. We make it our task to construct expert P r ” "Z?„ tliev C an ; to take advantage 
characterized by incomplete knowledge; to ad just themse ve possi ble (they need not assume that 

of the opportunities they can find in it; and f e h problem f possible ( hey more , 

rr ; 1 r,-*-»— 

Newell (1962) points out two potential difficult*!i which n™st b ^ es Lngers) musl 

adopt the actor problem solving methodology F “; 'J{ "“he fori of partial Information that can 
sometimes contain strategies, not Just ta,^ °™ * formll la „ g „age must b. 

maltnTan" XZ ™-“" S a«S nature of actors which are detegated snbtasKs 
to help control aimless thrashing. 

W e woutd tth, ,o wipi aaatiiaJa : a8-ga!aLgaA^s^j^ca^^^-^^ 

metaphor can be realiz e d in practic e;. At t is_pom n fi J future it will be possible to 

-‘Uicant fraction of the expertise and communication ability 

of a small scientific subfield. 


<f*S- 
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PLASMA has been designed to provide the basis for the implementation of a Programming 
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Apprentice for expert programmers. The behavioral programming methodology which PLASMA is 
intended to facilitate owes a tremendous intellectual debt to the concepts in SIMULA ^‘rtwistle et al. 
1973, Palme 1973]. We are indebted to Alan Kay for calling our attention to these virtues of SIMULA. 

The current implementation of PLASMA was designed by Carl Hewitt and has been 
implemented in LISP over the last year by a team of people whose principal members were Russ 
Atkinson, Tom Downey, Carl Hewitt, Marilyn Mclennan, and Howie Shrobe. The implementation has 
been accomplished using a set of LISP macros implemented by Russ Atkinson that make LISP into a 
very limited subset of PLASMA. Howie Shrobe put the system together in the fall semester of 1975. 
This spring Marilyn McLennan has brought the system to a usable state. Tom Downey and Jerry 
Morrison have implemented a modular format printer for PLASMA programs. Car! Hewitt and Russ 
Atkinson have designed modular primitives for the implementation of parallelism and synchronization 

in PLASMA. 
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SECTION X — APPENDIX: Introduction to PLASMA 


X.l — Sequences and Collections 

We will begin by presenting some very simple PLASMA scripts and gradually work our way up 
to more complicated examples. 

Meta-syntactic variables will be underlined. 

We note initially that [Aj A 2 ... A^Jmeans an ordered sequence of the actors Ajthrough 
AflWhereas {Aj A 2 ... A^means a unordered collection of the actors Ajthrough A^Thus [3 ’b]is not 
equivalent to [ b 3]although {3 'bjis equivalent to j’b 3}.Also collections behave differently from 
mathematical sets in that (3 1 'b 3}is not equivalent to {3 'bjbut is equivalent to {3 3 ’b}. 

Thus PLASMA has syntactic delimiters which are used consistently for the following different 
purposes: 

[...] delimits an ordered sequence of elements 
{...} delimits an unordered collection of elements 
(...) delimits an expression in PLASMA 


X.2 — Transmitters 

A simple syntax for sending an actor M(called the message) to an actor Trailed the target) is: 

(T <= M) 

or the following, which is entirely equivalent® 

(M => T) 

Thus, 

(['this 'is 'a 'simple 'sentence] => parser) 

will send a sequence of the five symbols 'this, 'is, 'a, 'simple, and 'sentence to the actor denoted by 
parser. 


3: The reason for having two different syntactic forms for the transmission of a message is that often 
it is more readable to have the expression for the message before the expression for the target or vice 
versa. The difference is particularly noticeable when one is much smaller than the other. 
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Since it is very common to want to send a sequence of arguments to an actor, a simple syntactic 
form is needed for this purpose. For example the notation used above would require us to write 
(+ <!S [ x y 2 ])in order to compute the sum of x, y, and z. whereas we would prefer use the syntax 

(+ x y z). 

In PLASMA, as in LISP, an expression of the form (Ej E 2 ... E„)ordinarily denotes an ordinary 

procedure call with procedure | x and arguments Ej,.and E„. Since PLASMA also uses parentheses as 

the delimiters of special syntactic forms, it needs to have some mechanism to distinguish special syntactic 
forms such as (f <= [3 4])from ordinary procedure calls so that <= is not taken to be the second 
argument of f. PLASMA uses RESERVED SYMBOLS in parenthesized expressions for this purpose. 
For example both =>and <=are reserved symbols. Transmitters using the reserved symbols =>and <*are 
read as forms of the verb "SEND". For example (1 <= [1 3])would be read as "f is sent the sequence 1 
3", or "a sequence of 1 and 3 is sent to f. 

For example 

(factorial 3) is equivalent to (factorial <= [3]) 

(generate) is equivalent to ([] => generate) 

Note that when either of the transmitter arrows <=or =>is written 
out explicitly in a special syntactic form, there is always one 
expression before the arrow and one after it. 

Also note that arithmetic can be expressed in infix notation as 
well as prefix notation. Arithmetic expressions are implemented 
in PLASMA by making arithmetic symbols such as + and * 
reserved symbols so that special modules associated with these 
symbols can process the expression in which they occur when the 
script is reduced. 

The syntactic forms 

( target <® message ) and ( message => target) 

are designed to direct the eye of the reader along the normal flow of control of the message to the 
target. The transmitters of PLASMA are a generalization of the functional applications in the lambda 
calculus of Church which were defined in terms of substitution semantics. The semantics of 
transmitters are behaviorally defined in terms of events in the actor message-passing model. 
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X.3 — Pattern Matching 

Pattern matching is used in PLASMA to recognize actors which satisfy a simple description and 
to bind the answers to simple requests. The process is meant to be quite intuitive. For example The 
prefix = in front of an identifier name in a pattern can be used to bind the identifier to the 
corresponding object being matched. For example typing 

(match [=x =y] to [3 4]) 

can be used to bind x to 3 and y to 4 


X.4 - Receivers 

Corresponding to the syntax for sending messages is a syntax for their reception. A PLASMA 
message-receiver has the following syntax: 

(=> pattern 
body ) 

where the reserved symbol s>is read as "RECEIVE". Note the use of the three horizontal bars for the 
shaft a receive arrow as opposed to the use of two horizontal bars for a transmitter arrow. If an actor 
with the above definition is sent a message which matches patternt hen bodyw ill be evaluated in the 
environment resulting from the pattern match. For example the PLASMA expression 

<[5 7] => 

;send the tuple whose first element i s S and second element 7 
(=> [=x =yj ;to a receiver which names the first element of the sequence received x and the second y 
(x + y))) ;and replies with the sum of x and y 

evaluates to 12. 

For the sake of exposition we will call the actor that (=> pattern body Creates a receiver. The 
behavior of the receiver is roughly as follows: when the receiver is sent a message, it matches it against 
the pattern. A PATTERN is an actor which decides whether it will match another actor called an 
object - the process is asymmetric. If the match is unsuccessful, then the receiver complains that the 
message is not acceptable. If the match is successful, the pattern creates a new environment (which 
contains the bindings that resulted from the matching process). The receiver then sends the body an 
eval message that contains the new environment. 

The syntactic form for receivers 


(s> pattern body ) 
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is designed to direct the eye of the reader along the normal flow of control with the message through 
the pattern into the body. The receivers of PLASMA are a generalization of the lambda expressions 
which were defined by Church in terms of substitution semantics. The semantics of receivers are 
behaviorally defined in terms of events in the actor message-passing model. 

All messages in PLASMA are received through patterns which should be kept qui te simple. 
Writing complicated patterns results in tortuous obscure code. Simple patterns are a good way to 
bind identifiers to values. Pattern matching in PLASMA is a generalization of the lambda calculus 
identifier binding mechanism. The semantics of receivers is behaviorally defined by axioms in terms 
of the actor message-passing model. 

The evaluation of a receiver results in an actor which has as its script the receiver and as its 
acquaintances the actors bound to the free identifiers of the receiver. For example if we type 

(a s [(3 + 2) (3 - 2)]) 

then we will create an actor [5 l]which is called a in the current local environment in which we are 
working. If we then type 


<s>t=x] 

(g X a))) 


, ;define f to be an actor which 
;tchcn it receivet a sequence with one element which will be called x 

;replie* with g of X and a 


an actor will be created which has [5 l]and the value of % as its acquaintances. 


X.5 — Conditionals 

Conditionals in PLASMA take two standard forms which are closely related. One form 
conditionally tests the value of an expression, the other conditionally tests the incoming message. The 
first is known as the rules expression and has the form: 


(rules an-expression 
(=> pattern | 

b2&l> 

(=> pattern^ 
bodyg ) 


;the rules for the actor an-expression are 
;if it matches pattern ^ then 
;reply with the value of body j 
;else if ii matches pattern^ then 
;reply with the value of bodyy 


(=> P«llern n 
body n )) 


;else it must match pattern. , so 
;reply with the value of body n 


The expression is matched against the successive patterns until it matches one of them; then the 
corresponding body is evaluated in the environment resulting from the pattern match. For example. 
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(rules (3 ♦ 4) 

(=> (even) 

5) 

(s> =n 
(2 * n))) 

evaluates to 14. 


;the pattern (even) teill match any even integer 

{the pattern =n will match any actor and bind n to that actor 

;return twice the value of n 


PLASMA uses a similar construct (called a casts statement) to conditionally dispatch on an 
incoming message. 


(cases 

(=> paltern ^ 

I body }) 
(=> patterng 
body 2 ) 


;the cases for a menage tent to this actor are 
;if the message matches pattern } then 
;reply with the value of body} 
;else if the message matches patterng then 
ire ply with the value of bodyg 


(s> pattern n 

bod^» 


;else the message must match pattern^ so 
;reply with the value of body^ 


A message sent to an expression of the above form is matched directly against the successive patterns 
until a match is found, whereupon the corresponding body is evaluated in the environment which 
results from the match. 


For example the following actor replies with yas to any even number it is sent; replies with no to 
any odd number; and is otherwise not-applicable. 


(casas 

(=> (even) 
y*s) 

(s> (odd) 
no)) 


X.6 — Definitions 

In general, typing an expression of the form 

( name s definition ) 

will cause PLASMA to do its subsequent evaluations in an environment which has been extended by 
binding name eo the value of definiiion. 
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For example the normal way to interactively define integer-exponentiationwhite working at a 
console would be to type: 

(integer-exponentiation s jinteger-exponenliation it defined to have the following behavior 

<=> f=b«se exponent] whenever it receivet a sequence of two argumentt called base and exponent 

(rules exponent ' the "*'** for the *'* 

(=>0 ,«/ >1 it 0 then 

ireply that the antwer it 1 

(=> (> 0) ;elte if it it greater than 0 then 

(base * (integer-exponentiation base (exponent - 1))))))) 

;the antwer it the bate timet the bate to the power of the exponent minut I 

As an obvious extension to our notation for definitions we allow a parenthesized expression on 
the left hand side of a definition. For example we can define integer exponentiation in terms of an 
infix operator as follows: 

((-base to-integer-power -exponent) a ;en expression of the form (=base » o-integer-power -exponent) 

( -u defined by the following behavior 

, i _, ;the rules for the exponent are 

(rules exponent 

;if it it 0 then 
;the answer it 1 

j g> ^ qj ;elte if it it greater than 0 then 

(base * (base to-integer-power (exponent - 1)))))) 

;the answer it the base timet the bate to the integer power of the exponent minus l 

Using the above definition (5 to-integer-power 3)evaluates to 125. In this way we can conveniently 
define new kinds of syntactic forms. 

MUTUALLY REFERENTIAL DEFINITIONS are easy to make using the reserved symbol let as 
follows: 


(let 

( name| s Dj) 

( name? s Dg) 

( name, , s 0„) 
then 
body ) 

which evaluates body in an environment with each namoj bound to the value of Dj. The equations are 
mutually referential in that any occurrence of a name) within a D* refers to Dj. 

As a special case of the let construct we use 


(name s definition) 
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as an abbreviation for 

{let 

( name = definition ) 
then 
name) 

Self-referential definitions are very useful in defining iterative, recursive, and co-routine control 
structures. They are also useful in defining data structures that need to know about themselves. 

At this point, we have enumerated all the ways to bind identifiers in PLASMA. Note that the 
definition of every symbol is lexically scoped and that there are no "glpbal variables”. 


X.7 — Unpack 


We will often make use of an extremely useful operator for sequences and collections called 
LLMF.Af±K which is abbreviated as an exclamation point: j oxpressioni s always equivalent to writing out 
all of the elements of the expression individually. Thus if sis bound to the sequence [3 4 5], then the 
value of [1 2 !s]is [1 2 3 4 5], Thus if the sequence [10 20 30 40 50]is matched against the pattern 
[=x -y •=*], then xwill be bound to 10, ywill be bound to 20, and zwill be bound to [30 40 50J in the 
environment which results from the match. Unpack is in essence the inverse of sequence brackets "[.„]". 

The unpack operator neatly cleans up the confusion in LISP between different ways to construct 
lists. Considering analogies between LISP lists and PLASMA sequences, the following similarities hold: 


[x y 2 ] is analogous to 
[x !y] is analogous to 
[!x y] is analogous to 
[!x !y] is analogous to 


(list x y z) 

(cons x y) 

(append x (list y)) 
(append x y) 


The chief benefit of the unpack notation is that the programmer no longer needs to concentrate 
on how to construct the structure by deciding whether to use CONS, LIST, or APPEND. Instead she can 
concentrate on what the structure should be by writting a pattern of what it should look like. For 
example the following PLASMA expression 


[!a [b !c d] !«] 

has the following LISP analog: 
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(append 

a 

(cons 

(cons 

b 

(appand c (list d))) 

•)) 


Page 53 


r*' 


X8 — Use of Sequences 

Sequences are a useful mechanism for the implementation of the kind of dialogues needed in the 
implementation of knowledge-based systems. They provide a useful common interface f ° r c ^ rou «"® 
control structures. We shall bind the elements and sub-sequences using pattern matching. The 
following pattern will bind f to the first element of a sequence and r to the rest: 

[=« !=r] 

For example if s is bound to the sequence [14 3 105]then typing the following expression in PLASMA 

(match [=1 !=r] to s) 

Will bind f to 14 and bind r to [3 105]. 

As an example of the use of sequences, we define the function sum-of which calculates the sum of 
all the elements in a sequence: 


(sum-of s 

(=> [=ihe-sequenee] 

(rules the-sequence 

(£> 11 
0 ) 

(=> [=the*next !=lhe-rest] 

(the-next ♦ (sum-of the-rest)))))} 

For example (sunv-o! [1 4 9])evaluates to 14. 

It is easy to build sequences. For example the following definition defines finite sequences of 
consecutive decreasing squares. 


{define the function sum-of 
;lo receive a sequence 
.;the rules for the sequence are 
{if the sequence is empty 
{then the sum is 0 
;else bind the next and the rest 
{then return the next plus the sum of the rest 






Pag* 54 


Control Structure 


(sequence-of-squares a 

(=> [=n] 

(rules n 


;the rule* for n are 
;if it i* 0 then 
;the answer is the empty sequence 
;else if it is greater than 0 then 


( 5 > 0 

[]) 


<s> 0 0) 

[(n * n) ! (sequence-of-squares (n - 1))])))) 



For example typing the following expression into PLASMA 


(match [=first !=rest] to (saquenca-of-squaras 4)) 


results in binding first to the value 16 and binding rest to the value [9 4 1J. Thus 
(sum-of (sequence-of-squares 4))evaluates to 30. 


X,9 — Delay 


For many applications, it is more efficient to generate the squares in the sequence of squares 
incrementally adopting a wait and see" approach as to whether the rest of the elements will be needed. 
To this end we introduce the delay operator which delays computation of the value of expression E 
until the value is needed. Suppose that ve is the value of the expression ( delay E). The value of | is 
not computed until the actor ve is sent a message. The first time ve is sent a message, the value of E is 
computed and remembered. Thereafter ve behaves exactly like the value of E. It is unreasonable to 
delay the evaluation of any expression which does not always evlaluate to the same object. 

P 

7 he delay operator can be used to refine the implementation of sequence-of-squares to produce 
an incremental-version: 

(incremenial-sequence-of-squares = 


(s> t=n] 
(rules n 



[n 2 ! (delay (incremenlal-sequenca-of-squaras (n - 1)))]}))) 


Typing the following into PLASMA 


(match [=11 *=rl] to (incremental-sequence-of-squares 10)) 
will bind fl to 100 and bind rl to an actor which is behaviorally equivalent to 
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(delay (incramantal-saquanca-of-squara# 9)) 

At this point in time the only square that has been computed is the square of 10. Typing 

(matrA [=f2 !=r2] to rl) 

will bind f2 to 81 and bind r2 to an actor which is behaviorally equivalent to 

(delay (ineramantai-sequanca-of-squaraa 8)) 


X.10 — Packagers 


PACKAGERS are a primitive mechanism in PLASMA for packaging actors together. They are 
very useful for packaging up the parts of a message. For example the notation [xj ... x n ] for a sequence 
is really just syntactic sugar for the package (sequence: xj ... x„). Thus evaluation of an ordinary 
function call of the form (( <* [x x ... x n ])sends a package which is the sequence of arguments to f. 
However, the use of positional notation within a sequence for the components of a message is neither 
mnemonic nor secure. The packagers of PLASMA allow the components of the package to be explicitly 
named and the physical representation to be hidden (for reasons of efficiency and cleanliness). They 
permit all of the components of the package which are of interest to be selected in parallel and the 
remainder of the components to be ignored (for reasons of modularity and extensibility). Additionally, 
packagers provide for both the privacy and security of messages since in order to have access to the 
contents of a package constructed by a particular packager, it is necessary to have access to that 
packager. Packagers are the primitive authentication mechanism of PLASMA. A packager can only be 
. taken apart by the packager which constructed it. 

Tp illustrate the use of packagers we shall define a packager for complex numbers. First we 
define packagers for the messages to which complex numbers must respond: 

(packager (real-part?)) 

(packager (imaginary-part?)) 

To make these abbreviations more convenient to use we define the following abbreviations. 


((raal-part =z) s 

((real-part?) => z)) 
((imaginary-part =z) s 

((imaginary-part?) = > z)) 


;the r*al-part of z i* computed by 
;tending a menage atking Z for it* real part 
;the imaginary-part of z «* computed by 
;tend a menage atking X for it* imaginary part 


Below we define a packager for complex numbers: 
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Control Structure 


(packager ( complex: { real: 7) ( imaginary; ?)) 


(=> ( complex : (real: =*) (imaginary: ay)) 
(cases 


{define a packager far complex numbert with real and imaginary component 


(=> (real-pari?) 


;if asked for the real pari then 
;return x 

,•*/ asked for the imaginary part then 

;return y 

{if asked for the sum with z then 
{return a complex number with 
;real component the sum of x and the real part of z 


x) 

(=> (imaginary-part?) 


y) 

(=> (plus: =z) 


(complex: 

(real: (x ♦ (real-part z))) 

(imaginary, (y + (imaginary-part z})))) 



(complex: 

(real: ((x * (real-part z)) - (y * (imaginary-part z)))) 
(imaginary ((x * (imaginary-part z» + (y * (real-part z))))))))) 


Notice the use of the packager complex: both to construct complex numbers and to take them 
apart into their real and imaginary parts. The above implementation is inefficient because of all the 
message passing involved in computing the values of (real-part z)and (imaginary-part z)when doing 
addition and multiplication of complex numbers. For example in the above implementation two such 
messages are required to compute the sum in the following sub-expression of the above program: 


(complex: 

(real: (x + (real-part 2 ))) 

(imaginary: (y + (imaginary-part z)))) 


We will demonstrate how the efficiency can be improved in a purely mechanical way without 
diminishing the generality of the implementation. The first step is to collect statistics of executions to 
determine which actors are very frequently sending messages to other. This will soon reveal that the 
expression (r«al-part z)quite often results in sending the message (real-part?)to 2 where z is of the form 


(complex: (real: rz) (imaginary: iz)) 


This suggests that special code for this case might be generated in-line to speed up the execution. 
Obviously the expression (real-part z)is completely equivalent to 


(rules z 


(=> (complex: (real: =rz) (imaginary =iz)) 

(real-part (complex: (real: rz) (imaginary: iz)) )j 


(else 

(real-part z})) 




Pu« 57 


Control Structure 

By replacing real-par! and complex: by their definitions and simplifying we obtain the following 
expression: 

(rules z 

(s> (complex : (real: srz) {imaginary. =iz)) 
rz) 

(else 

(real-par! 2 ))) 

By performing the above transformation on all expressions of the form (real-par! z)and 
(imaginary-part z)and then pulling out common sub-expressions the following more efficient 
implementation of the packager complex: has been derived: 

{packager {complex: {real: ?) {imaginary ?)) 

;define a more efficient packager for complex numbert with real anti imaginary component! 
(s> {complex: {real: *x) {imaginary ay)) 

(cases 

(=> ( real-part?) 
x) 

(=> {imaginary-part?) 

(s> {plus: = 2 ) 

(rules z 

(=> (complex: (real: =rz) (imafinary: aiz» 

(complex: 

(real: (x + rz)) 

(imaginary (y + iz)))) 

(else 

(complex: 

(real: (x + (real-par! z))) 

(imaginary (y ♦ (imaginary-part z))))))) 

(=> (times: =z) 

(rules z 

(=> ( complex: (real: =rz) (Imaginary: =iz)) 

( complex: 

(real: «x * rz) - (y * iz))) 

(imaginary ((x * iz) ♦ (y * rz)))) 

(else 

(complex: 

(real: ((x * (real-par! z)) - (y * (imaginary-part z)))) 

(imaginary ((x * (imaginary-par! z)) ♦ (y * (real-par! z)))))))))))) 

Note that PLASMA is ideally suited for the above kind of optimization by in-line substitution 
because identifiers in PLASMA (unlike many other languages) are completely transparent. An 
occurrence of identifier in PLASMA serves only to name the actor to which it is bound. In-line 
substitution is not always valid in languages like LISP 15 because of the SET primitive in the language. 

The presence of a primitive like SET (and other similar primitives in other LISP-like languages) makes 
optimization much more difficult. 










